GSoC23 — Workweek 9

Introduction

As a reminder, last time I wrote about the issue when multiple functors are connected to a single source. In that case it is unclear to which of the functors the interconnect path must be annotated.

This week I have spent some time in VVP to find out how to add input and output buffers to modules, so that this ambiguity can be solved.

I was also writing smaller tests to make sure that the implementation I am working on is functioning correctly, and to find out what situations are not annotated correctly.

VVP

My goal is to add input and output buffers to modules. This means I have to look where modules are elaborated: inside elaborate.cc.

Two functions are of special interest to us:

  • PGModule::elaborate_mod_
  • Module::elaborate

Once the top modules have been identified, they are elaborated via Module::elaborate. This function calls the elaborate functions for tasks, functions, classes, gates etc., anything that can be in a module. Gates can be either UDP devices or modules. If the gate is a module then the PGModule::elaborate_mod_ function will be called for it to be instantiated. This is where the input and outputs of the instantiated module are connected to the parent module - which is exactly where we want to add our buffers. Also noteworthy before the instantiated module is connected, it is itself recursively elaborated via Module::elaborate.

PGModule::elaborate_mod_ is quite long and took some time for me to understand. Luckily for us, there is already some logic to add input buffers. If need_bufz_for_input_port returns true, a buffer will be added to the current input.

For now, I set this function to always return true to continue with my work. Later I might add a -ginterconnect flag or something similar.

Tests

As mentioned in the introduction, I have written some smaller test cases that I am currently using to verify the current implementation - not everything works correctly so far.

For these few modules it is still possible to check the interconnection delays by hand (or rather by eye).

But once these tests work, I want to move on to larger designs. To do this, I want to create example designs with interconnection delays using the OpenLane/OpenROAD flow, because that's what this project is supposed to enable. For these designs, I plan to write some scripts to automatically check the delays for me.

Summary

That's it for this week. Next week I will work on adding output buffers, fixing up all the smaller test cases, and then go on to creating bigger ones with OpenLane.

See you then!